The present invention relates to a software development support device capable of guiding a software designing operation, managing and checking the information about designed documents and designed parts or elements, etc., and smoothly aiding software development and a designing operation based on a structured design method.
Recent high-level diversified demands for information and communication systems have largely affected the involved software, thereby resulting in a large-scale complicated software, extending a development period, requiring the increasing number of persons involved in the development, and covering increased costs. As a result, new effective technologies are required to efficiently design and realize the optimum software.
In the conventional software design technologies, designing restrictions are determined by each unit in a developing organization, and each design is described manually or with a word-processor according to the designing restrictions, precedents, or customs. The restrictions are observed depending on the conscience and personality of each of the members in the organization. The description and the representation of a designed document also depends on the personality of an author.
On the other hand, a computer aided software engineering (CASE) is proposed as the technique of supporting software development through computers with the increasing number of programmers involved. Some conventional CASE tools contain programs for supporting design description through an editing unit, and have a predetermined representation format for preparing a designed document. According to the representation format, a software designer prepares his design and writes the software in step units. At this time, the tool provides the original design and the relationship information used in detailing the document.
In maintaining designed documents, they are stored in DASDs or floppy discs of word-processors and computers, and each segment of the design is managed by its author although there is a general administrator. Besides, a designer in the downstream (a designer who designs the more detailed parts) can update a designed document written by a designer in the upstream.
In designing software manually or with a word-processor according to predetermined restrictions, or in designing software through a conventional CASE tool as described above, there are some problems which deteriorate the quality of the software and prevents the efficiency in operations.
In the conventional methods, there can be problems caused by that specifications to be described, levels of the contents, or procedures of the specifications are not uniquely prescribed. That is, no unique prescription causes recognition gaps in a designing process among developers (designers and administrators) or among processes (designing methods and realizing methods according to the original design). The recognition gaps may lead to oversights or misunderstandings of specification segments as they grow when the steps proceed to the manufacturing and testing processes, thereby reducing the operation efficiency.
That is, when a system development is performed at a customer's request, there are several development procedures such as what type of a CPU is used to develop a system, how to execute a parallel process, how to segment a parallel process, how to compose a final program statement, etc. In the conventional methods, there are no prescriptions on such development levels. This is why the recognition gaps arise among development processes (designing methods and realizing methods according to the original design).
Additionally, when a designed document is prepared, it is written manually or with a word-processor in the conventional method according to development restrictions, precedents, or customs. However, differences or mis-description often arise in the contents and representation of description. Besides, since the prescription on designed parts and the relationships among them can be determined by each designer in the conventional method using an existing CASE tool, a graphic symbol written by a designer during an editing process can be interpreted differently by readers, thereby causing a misunderstanding between a writer and a reader. This may deteriorate the quality of software or reduce the efficiency in operations.
There are also problems in the storage and management of designed documents. Conventionally, each designer stores and manages the documents in DASDs or floppy disks. However, if a large volume of designed documents for a large-scale software are stored in the above described conventional method, only a designer knows the location of his segment of the whole designed document. Therefore, there arises a problem that the following processes of referring to or maintaining the designed documents may not be performed smoothly. To prevent such a disorder, the location of each level of designed documents is described in writing, or orally notified to each developing member. However, this is not sufficient and incurs the reduction of efficiency in operations.
There arise problems also in taking over a job from a designer in the upstream to a plurality of designers in the downstream. Since a designer in the downstream can update a designed document written by a designer in the upstream in the conventional method, errors may arise in the designed document referred to by a plurality of designers in the downstream. Additionally, in detailing a document from the upstream to the downstream, the same designed parts are duplicated or described by a copy function. During these operations, errors can be made by mistake. If a document is written in detail with these mistakes contained therein, an enormous effort must be made to correct them in the later process, thereby reducing the development efficiency and deteriorating the quality of the resultant product.
Simple mistakes are often made in a writing operation performed manually or with a word-processor, such as missing a letter in a description, missing a connection between symbols in a drawing, etc. However, in the case of a manual writing, errors must be detected only by manually checking the designed document. Since even a word-processor cannot identify graphic symbols, errors in them also must be detected manually by checking an edition screen of a document or a printed result. The problem is that all these mistaken errors cannot be detected automatically.